METHOD OF AUTHENTICATING A CLIENT DEVICE FROM A SERVER USING A SECRET ELEMENT

专利摘要:
The invention relates to a method for authenticating a client device holding an authentication token generated using a pseudo-homomorphic function and from a secret element (PIN), with a server, comprising: - generating (A1), by the client device, a proof of knowledge of the secret element from a masked proof generation key with mask data, said masked proof generation key being constructed so as to prove the knowledge of said secret element without disclosing it, - transmission, to the server, by the client device of said proof of knowledge of the generated secret element (A2) and the authentication token (J) masked to the using the mask data (A3), - checking the validity of the masked authentication token (A4), and the validity of the proof of knowledge by the server (A6).
公开号:FR3027177A1
申请号:FR1459804
申请日:2014-10-13
公开日:2016-04-15
发明作者:Julien Bringer；Herve Chabanne；Olivier Cipiere；Rodolphe Hugel；Roch Lescuyer
申请人:Morpho SA；
IPC主号:

专利说明:

[0001] BACKGROUND OF THE INVENTION The present invention generally relates to the authentication of a client with a server. The invention more specifically relates to a secure authentication method using a secret element protected against the compromise of the server or the client. STATE OF THE ART In the context of the existing authentication methods, a client generally provides a server with proof of his identity by providing a secret element of his own, such as a password or a PIN code. In order to verify the validity of the secret element sent by a client, the server can store, possibly encrypted, the secret elements of customers enrolled with him.
[0002] In case of compromise of the server, an attacker accessing the memory of this one could take knowledge of the secret elements stored in clear and use them in a fraudulent way to pass to the waiter for the customers whose secret element he obtained . If stored in encrypted form, exploiting the contents of the memory by an attacker is more difficult but not impossible. In addition, the secret element of a client can appear in decrypted form in the memory of the server during its authentication. Espionage of server memory content by an attacker during the execution of the authentication then allows the attacker to become aware of the secret element of the client being authenticated.
[0003] In order to make the authentication insensitive to a compromise of the server, certain methods propose to store the secret element of the user in the memory of the client and to verify locally the knowledge of this secret element by the user. Nevertheless, such methods are susceptible to compromise of the client memory. Especially since it is generally a lightweight equipment, such as a mobile phone or a personal computer, often less secure than equipment such as a corporate data server. In addition, the existing authentication methods can be sensitive to replay attacks in which an attacker reuses data previously transmitted by a client and impersonates that client with a server. This data may for example have been obtained by a man-in-the-middle attack by which the attacker intercepts communications between the client and a server.
[0004] There is thus a need for an authentication method enabling a client to prove to a server its knowledge of a secret element while being insensitive to a compromise of the memory of the client or the server and the attacks by replay, without requiring significant computing power which would make it difficult to implement on a client such as a mobile phone. SUMMARY OF THE INVENTION To this end, the present invention thus relates in a first aspect to a method of authenticating a client device with a server using a secret element, said client device holding an authentication token generated using a pseudo-homomorphic function and from said secret element, said method comprising steps of: 3-generation, by the client device, of a proof of knowledge of the secret element from a masked proof generation key with a first mask data, said first mask data being non-public random data known only to the client device and said masked evidence generation key being constructed so to prove the knowledge of said secret element without disclosing it, - transmission, to the server, by the client device of said proof of knowledge of the secret element generated, 1 0 - transmission to the server by the client device of the masked authentication token using the first mask data, - verification by the server of the validity of the masked authentication token received, 15 - verification by the server of the validity of the proof of knowledge The server can thus verify that the client device has an authentication token, and that the client device is aware of the secret element that was used to generate this authentication token, without that the authentication token is unveiled through the use of the first mask data. In one embodiment of the method according to the first aspect, this method may further comprise a step of obtaining by the server a proof verification key associated with said proof generation key. The step of verifying the validity of the proof of knowledge then comprises a verification by the server of the validity of the proof of knowledge using the obtained proof verification key 30. According to an implementation variant, the server verifies the validity of the proof of knowledge from the received masked authentication token. Such an authentication token may comprise an encryption token obtained by encryption from said secret element using a pseudo-homomorphic encryption function. In one embodiment of the method according to the first aspect, the authentication token further comprises a signature token corresponding to the result of the signature of the encryption token using a pseudo-homomorphic signature function. the step of transmitting the masked authentication token comprises the transmission by the client device to the server of the encryption token held hidden by the first mask data and the transmission by the client device at the server, the signature token held hidden using the first mask data; - The step of checking the masked authentication token includes checking, by the server, the validity of the signature of the masked signature token received from the received masked encryption token.
[0005] In one embodiment of the authentication method according to the first aspect: the step of generating a proof of knowledge of the secret element comprises the transmission of a challenge by the server to the client device, and generating, by the client device, a signature data obtained by signing the challenge received using said masked evidence generation key, - the step of transmitting to the server by the device The client of said secret element knowledge proof comprises transmitting, by the client device, said signature data to the server.
[0006] In one embodiment of the authentication method according to the first aspect: the step of transmitting the masked authentication token comprises the transmission, by the client device, to the server of the encryption token 5 that is held hidden using the first mask data, - the step of obtaining the proof verification key from the received masked authentication token includes the decryption, by the server, of the masked encryption token received at the use of the pseudo-homomorphic encryption function to obtain a proof verification key; - the step of verifying the validity of the proof of knowledge includes the verification by the server of the validity of the signature the signature data received using the obtained proof verification key.
[0007] The server can thus verify that the client device does indeed have an encryption token and the associated signature token, and that the client device is aware of the secret element that was used to generate this encryption token, without the The cipher token or the signature token are not disclosed through the use of the first mask data. During a prior enrollment phase, said authentication method according to the first aspect may comprise steps of: determination of the secret element by the client device and generation of the encryption and signature tokens. In a first mode of implementation, during the enrollment phase, the step of determining the secret element may comprise the selection of the secret element by a client holding the client device and the step generation of the encryption token may include the generation of the encryption token by the client device. The secret element thus remains unknown to the server, protecting the authentication method from compromising its memory. In a second embodiment, during the enrollment phase, the step of determining the secret element may comprise the selection of the secret element by a customer holding the client device and the transmission of the secret element selected to the server, and the steps of generating the encryption and signature tokens may comprise the generation of the encryption token and signature token by the server and the transmission of these tokens to the client device.
[0008] The implementation of the enrollment phase with a trusted server is thus made simpler and does not require any calculation on the part of the client device.
[0009] The step of generating an encryption token may include computing a hash of the secret element from a hash function and encrypting said hash using the orphan pseudohomom encryption function.
[0010] The secret element is thus used during the generation of the encryption token only in the form of a hash which limits the risks that an attacker can find the secret element from the encryption token in case of compromise. memory of the client device.
[0011] In a third mode of implementation, the step of generating the encryption token can include the generation by the server of a temporary secret element, the generation of a temporary encryption token from the element temporary secret, the transmission of the temporary secret element and the temporary encryption token to the client device and the generation by the client device of an encryption token from the temporary encryption token, the temporary secret element and the secret element, and the signature token generation step may include generating a temporary signing token by the server by signing the temporary encryption token, transmitting the temporary signing token to the client device, and generating by the client device of a signature token from the temporary signature token, the temporary secret element and the secret element. This mode of implementation allows the client device to obtain a secret element of its choice and the corresponding encryption and signature tokens without transmitting any of these elements to the server, thus limiting the risks of interception or reuse of these elements. data due to compromised server memory.
[0012] The generation of the temporary encryption token may include computing a hash of the temporary secret element from a hash function and encrypting said hash using the pseudo-homomorphic encryption function.
[0013] The step of calculating a hash of a secret element may comprise calculating a hash of said secret element and at least one additional secret element from a hash function. This makes it possible to impose on a user wishing to authenticate the possession of an additional secret element, possibly linked to a material element, thus further limiting the risks of identity theft. The generation of an encryption token C from a secret element 5a can be carried out using the following formula: C = Enc (gAP) with g a generator of a high order group and P = h (s, a) with s a random number (salt), h a hash function, a that can be equal to the secret element (PIN) or a temporary secret element and Enc the pseudo-homomorphic encryption function.
[0014] During the enrollment phase: the step of generating the encryption token can be performed by the client device; and the step of generating the signature token may comprise: the masking of said encryption token using a second random mask datum known only to the client device; the transmission to the server of said token of hidden encryption; the generation by the server of a second signature data by signing the received masked encryption token using the pseudo-homomorphic signature function; the transmission by the server of the second signature data to the client device; said signature token being obtained from said second signature data using the second mask data.
[0015] This makes it possible for the server to generate signature data enabling the client device to obtain a signature token corresponding to its encryption token, without disclosing this encryption token, thus limiting the risks of a replay attack in the event of a failure. interception of communications between the client device and the server.
[0016] The client device can check the validity of the signature of said second signature data. This makes it possible to detect possible corruption of the signature data, whether because of an error at the time of its generation or a problem during its transmission. The client device ensures that the validity of the signature token obtained can be verified during the authentication phase to avoid being in a situation where it could not authenticate for lack of valid signature token.
[0017] The cryptographic and signature functions may be asymmetric functions. During an initialization phase, the authentication method according to the first aspect may comprise the implementation by the server of the steps of: generating a pair of asymmetric signature keys to implement the signature function pseudo-homomorphic; generating a pair of asymmetric encryption keys to implement the pseudo-homomorphic encryption function; transmitting the public encryption key of said pair of asymmetric encryption keys and the public signature key of said pair of asymmetric signature keys so that the client device performs the ciphers and can check the signature tokens issued 25 by the server using said public keys and that the server performs the decryptions and generates the signature tokens using the private keys of said pairs of asymmetric keys. Said encryption and / or signature keys can be associated with an identifier of the client holding the client device 3027177 10 Identity theft by an attacker is thus made more difficult since the authentication will require the use of the encryption tokens and signature corresponding to the identity of which he claims.
[0018] In a first implementation variant, said encryption and / or signature keys are mapped to an identifier of the customer holding the client device in a database.
[0019] Such a variation allows the server to easily determine which keys to use when authenticating a certain client device. In a second implementation variant, said encryption and / or signature keys are derived from a hash of the identifier of the customer holding the client device. Such a variant makes it possible to keep secret the correspondence between the identity of a client and the associated keys even in the event of compromise of the memory of the server.
[0020] According to another embodiment, the authentication token can be generated further by means of a secret user key. Such an implementation mode allows the server to verify during an authentication that the token provided by a client device has been generated using the secret user key associated with this client device, thereby making the client authentication token of a client device unusable by another device. The authentication token can be obtained by encrypting the secret user key and the proof generation key with a second pseudo-homomorphic encryption function.
[0021] This token thus makes it possible both to prove the knowledge of the proof generation key and to prove that the client device supplying the token to authenticate is the same as that for which the token has been generated. The client device may further hold a first encrypted token obtained by encrypting the secret user key using a first pseudo-homomorphic encryption function and further comprising a step of transmission by the client device to the server. the first encrypted token. This allows the server during authentication to check the coherency of the authentication token with this first additional encrypted token 15, making it more difficult to fraudulently use the authentication token. The authentication method according to the first aspect may then comprise a step of determining a first parameter by the client device and a second encrypted token obtained by encrypting the secret user key and said first parameter to the using the first pseudo-homomorphic encryption function and a step of transmission by the client device to the server of the second encrypted token.
[0022] The step of generating a proof of knowledge of the secret element of the method according to the first aspect may comprise the transmission of a challenge by the server to the client device, and the generation by the client device of data of signature obtained from the first parameter, a first hash value and the masked proof generation key, said first hash value being obtained from the challenge received, from the first encrypted token, of the token 3027177 12 of masked authentication using the first mask data and the second encrypted token, the step of transmitting to the server by the client device of said proof of knowledge of the secret element of the method according to the first aspect 5 can then comprise the transmission by the client device, said signature data to the server. This makes it possible to bind the secret user key k and the first parameter t, corresponding to an element of the proof of knowledge of the secret element, in the second encrypted token. The verification of this proof of knowledge, and therefore the authentication of the user, thus requires that the client device provide the server with four elements (the proof of knowledge, the authentication token and the first and second encrypted tokens) coherent, that is to say, corresponding to the same secret element P, 15 to the same secret key k, to the same first parameter t and to the same masking data R. In such an embodiment, the verification steps by the server of the validity of the masked authentication token received and the validity of the proof of knowledge may comprise: the calculation of a second value of hash from the challenge, the first encrypted token, the authentication token masked and the second encrypted token received; calculating a first decrypted token by decrypting the first encrypted token using the first pseudo-homomorphic encryption function; calculating a proof verification key by decrypting the masked authentication token using the second pseudo-homomorphic encryption function; Computing a second decrypted token by decrypting the second encrypted token using the first pseudo-homomorphic encryption function; checking the validity of the received masked authentication token 5 and the proof of knowledge from the received signature data, the first decrypted token, the second decrypted token, the second hash value and the key of proof verification.
[0023] The server thus simultaneously checks the validity of the authentication token J and the proof of knowledge Z, these verification operations providing proof that the user device has the correct secret element and that the elements provided correspond to the same key. secret user.
[0024] According to a second aspect, the present invention relates to a computer program product comprising program code instructions for executing the steps of the method according to the first aspect when said program is executed on a computer.
[0025] According to a third aspect, the present invention relates to a client device characterized in that it is configured to: hold an authentication token generated using a pseudo-homomorphic function and from said secret element, Generating a proof of knowledge of the secret element from a masked proof generation key with a first mask data, said first mask data being non-public random data known only to the client device and said key of masked proof generation being constructed so as to prove the knowledge of said secret element without disclosing it, - transmitting to the server said proof of knowledge of the secret element generated, - transmitting to the server the authentication token masked to the using the first mask data, so that the server verifies the validity of the received masked authentication token and verifies the validity of proof of knowledge. According to a fourth aspect, the present invention relates to an authentication server of a client device using a secret element, said client device holding an authentication token generated using a pseudo function. and -omomorphic and from said secret element, said server being configured to: - receive a proof of knowledge of the secret element generated from a masked proof generation key with a first mask data and transmitted by the device client, said first mask datum being a non-public random datum known only to the client device and said masked evidence generation key being constructed to prove knowledge of said secret element without disclosing it, receiving the masked authentication token using the first mask data, - check the validity of the received masked authentication token, - check the valid the proof of knowledge.
[0026] Finally, the present invention relates in a fifth aspect to a system comprising at least one client device according to the third aspect and a server according to the fourth aspect. Such computer program products, client and server devices have the same advantages as those evoked for the methods according to the first, second, third, fourth or fifth aspects.
[0027] DESCRIPTION OF THE FIGURES Other features and advantages will become apparent from the description which follows, which is purely illustrative and not limiting and should be read with reference to the appended figures, in which: FIG. 1 illustrates a flowchart representing the different phases an authentication method according to the invention.
[0028] FIG. 2 illustrates a flowchart representing an embodiment of an authentication phase of an authentication method according to the invention. FIG. 3 illustrates a flowchart representing a mode of implementation of an initialization phase of an authentication method according to the invention. FIG. 4 illustrates a flowchart representing a first embodiment of an enrollment phase of an authentication method according to the invention. FIG. 5 illustrates a flowchart representing a second mode of implementation of an enrollment phase of an authentication method according to the invention. FIG. 6 illustrates a flowchart representing a third embodiment of an enrollment phase of an authentication method according to the invention.
[0029] FIG. 7 illustrates a flowchart representing a first embodiment of an authentication phase of an authentication method according to the invention. FIG. 8 illustrates a flowchart representing a second embodiment of an authentication phase of an authentication method according to the invention.
[0030] FIG. 9 illustrates a flowchart representing a third embodiment of an authentication phase of an authentication method according to the invention. FIG. 10 illustrates a flowchart representing an implementation mode in which the authentication token is generated based on pseudo-homomorphic double encryption on elliptic curves. DETAILED DESCRIPTION OF AT LEAST ONE EMBODIMENT 10 An implementation mode relates to a method of authenticating a client device with an authentication server using a secret element such as one or several passwords, a PIN code, a key, a biometric data item, or a key derived from another data such as a biometric data, a user identifier or a mobile identifier. Such a secret element will be generically denoted PIN in the remainder of this document. In order to protect the authentication process of the client device with the authentication server against compromise and replay attacks, this mode of implementation is intended to enable the client device to prove its knowledge of a secret element. particular without revealing it, without storing it in memory, and without the authentication server being aware of this particular secret element. For this, as illustrated in FIG. 1, in a preliminary initialization phase P1, the server generates the elements (keys, integers, vectors, etc.) necessary for the implementation of the subsequent enrollment and authentication phases. . During the enrollment phase P2, the client enrols with an enrollment server and obtains an authentication token J generated from said PIN secret element. The authentication server may be separate from or confused with the enrollment server. In the following paragraphs, both servers are assumed to be merged. Then, in an authentication phase P3, the client device 5 authenticates with the server by proving its knowledge of said PIN secret element without disclosing it. For this, as represented in FIG. 2, said authentication phase P3 comprises a knowledge proof generation step A1 during which the client device generates a proof of knowledge of the secret element PIN generated using a masked proof generation key with a first mask datum 3, said first mask datum being a non-public random datum known only to the client device and said masked proof generation key being constructed to prove knowledge of said element secret PIN without disclosing it. Said authentication phase P3 also comprises a first transmission step A2 during which the client device transmits to the server said proof of knowledge of the secret element generated.
[0031] According to one variant, the authentication phase may comprise several data transmissions between the client device and the server to result in the transmission to the server of the proof of knowledge of the secret element. For example, the client device may generate a first portion of the proof of knowledge and then transmit it to the server. It can then send a challenge to the client device and it can then generate a second part of the proof of knowledge from this challenge and transmit it to the server. Said authentication phase P3 also comprises a second transmission step A3 during which the client device 30 transmits the masked authentication token J to the server using the first mask data R.
[0032] The first transmission step A2 and the second transmission step A3 may be confused, the proof of knowledge and the authentication token being then transmitted at the same time to the server by the client device.
[0033] Said authentication phase P3 also comprises a first verification step A4 during which the server verifies the validity of the received masked authentication token. Said authentication phase P3 finally comprises a second verification step A6 during which the server verifies the validity of the proof of knowledge. This verification can be performed from the masked authentication token received. Said authentication phase P3 may also comprise a obtaining step A5 during which the server obtains a proof verification key associated with said proof generation key. The verification step A6 of the validity of the proof of knowledge then comprises a verification by the server of the validity of the proof of knowledge using the proof verification key.
[0034] The authentication token is sent by the client device to the server in a masked manner so that no one, not even the server, can reuse it during subsequent authentication to impersonate the client device. Thus, the client device can, through the proof of knowledge, prove without revealing its knowledge of the secret element to which the authentication token corresponds. The client device can also prove the validity of the authentication token. The authentication token J may be stored in the internal memory of the client device or in an external memory connected to the client device through a local connection such as a USB connection or a network connection. The user authentication token can thus be stored partially or totally on a shared network storage location between several client devices belonging to the same user.
[0035] The authentication token J can be generated using a pseudo-homomorphic function in several ways and different implementations follow from it and are described below. A pseudo-homomorphic function f is a function compatible with masking such that, for a masking operation M such as the multiplication by a mask datum a, there exists an operation O, such as the exponentiation by a, such that O ( f (x)) = f (M (x)), i.e. (f (x)) λ = f (x * a). Such a function can also be homomorphic between two operations Op1 and Op2 if performing the operation Op2 on (f (x), f (y)) makes it possible to obtain f (x Op1 y). the implementation mode in which the authentication token is generated from pseudo-homomorphic signature and encryption functions: According to a first embodiment of authentication token generation, the authentication token J may comprise an encryption token C obtained by encryption from said PIN secret element using a pseudo-homomorphic encryption function Enc. It may also further comprise a signature token S corresponding to the result of the signature of the encryption token C using a sign pseudo-homomorphic signature function. Initiation phase More precisely, during a preliminary initialization phase, the server can begin by generating the keys necessary for the encryption and signature functions, the latter possibly being asymmetric functions.
[0036] With reference to FIG. 3, during a first El key generation step, the server can generate a pair of asymmetric signature keys (pkSign, skSign) dedicated to the implementation of the pseudo signature algorithm. homomorphic Sign. Such a signature algorithm may be a multiplicatively homomorphic algorithm such as the Gennaro algorithm according to the following reference: Rosario Gennaro, Jonathan Katz, Hugo Krawczyk, Tal Rabin, Secure Network coding over the integers, Public Key Cryptography 2010, 142-160. During a second key generation step E2, the server 15 can generate a pair of asymmetric encryption keys (pkEnc, skEnc) dedicated to the implementation of the pseudohomomorphic encoding algorithm Enc. Such an algorithm may for example be the El Gamal algorithm or the Paillier algorithm according to the following references: Taher El Gamal, A public-key cryptosystem and a signature scheme based on discrete logarithms, IEEE Transactions on Information Theory 31 (4) , 469472, doi: 10.1109 / TIT.1985.1057074, CRYPTO'84, 10-18 and Pascal Paillier, Public-key cryptosystems based on composite degree residuosity classes, EUROCRYPT 1999, 223-238. During an E3 key transmission step, the server can transmit to the client device the public encryption key of said asymmetric encryption key pair pkEnc and the public signature key of said asymmetric signature key pair pkSign. Alternatively, when the encryption algorithm is intended to be implemented only by the server, it only transmits to the client device 30 the public signature key.
[0037] The client device thus has a signature key enabling it to check the validity of the signature tokens generated by the server. The client may also have an encryption key enabling him to generate a decryption token decrypted by the server.
[0038] The server has corresponding private keys enabling it respectively to generate signature tokens and to decrypt encryption tokens. According to one embodiment, the encryption and / or signature keys may be associated with an identifier of the client holding the client device. Such an association enhances the protection of the authentication method against attacks by for example requiring that an encryption token used by a client device has been generated with the encryption key associated with that client device, otherwise the authentication operations performed on the server side will fail and the client device will not be authenticated. To do this, said encryption and / or signature keys can be mapped to an identifier of the customer holding the client device in a database that can be stored in storage means of the server. Alternatively, said encryption and / or signature keys can be derived from a hash function of the client identifier holding the client device, thus avoiding having to store hard correspondence at the server. Such a hash can be generated by a hash function on integers or on elliptic curves. Enrollment Phase The method can then be followed by an enrollment phase of the client device with the enrollment server during which the client device obtains the authentication token J.
[0039] This phase may comprise a step of determining a secret element by the client device E4 and a step of generating an encryption token E5 and a step of generating a signature token E6. According to a first embodiment shown in FIG. 4, the step of determining the secret element E4 comprises the selection of the secret element by a client holding the client device and the step of generating the encryption token E5. includes generating the encryption token by the client device. More specifically, the step of generating the encryption token E5 may comprise a first step of calculating a hash E51 in the course of which a hash of the secret element is calculated by the client device from a function of hash. For example, the client device calculates a hash P = h (s, PIN) with h a hash function, s a random number called salt and PIN the secret element chosen by the client during the determination step of the secret element E4. Alternatively, the first step of calculating an E51 hash may include computing a hash of said secret element and at least one additional secret element from a hash function. Such an additional secret element may for example be an additional key or an element related to the configuration of the client device such as a string derived from the hardware configuration of the client device, an address of a particular piece of data in memory etc. The step of generating the encryption token E5 may then comprise a first encryption step E52 during which the client device generates an encryption token by encrypting a data item that is a function of the secret element PIN chosen at the time. using its public encryption key pkEnc dedicated to the implementation of the encryption function Enc. For example, the client device may generate an encryption token C equal to Enc (gAP, pkEnc) with P the hash calculated during the first step of calculating a hash E51 and g a generator of a high order group. The client device thus has an encrypted version of the chosen secret element.
[0040] Generator g may be the same for all client devices or may be specific to a given client device. In the latter case, the correspondence between the generator g chosen for each client and the identity of each client can be stored in a server-side database or the generator g can be generated by encoding 10 points on elliptic curve. This generation of the encryption token is followed by the generation of a corresponding signature token. In this first embodiment, the step of generating a signature token E6 may comprise a first masking step E61 during which the client device masks the encryption token C with the aid of a second mask data a. This second mask data is random data known only to the client device. The masked encryption token may be noted CAa. By virtue of the homomorphism property of the encryption function Enc, this masked encryption token corresponds to the result of the encryption of the secret element masked by the second mask data item a. Indeed, CAa = (Enc (gAP)) ^ a = Enc ((gAP) ^ a) = Enc (g ^ (P * a)) The step of generating an E6 signature token can then comprising a first token passing step E62 during which the client device transmits the masked encryption token CAa to the server.
[0041] The step of generating a signature token E6 may then comprise a first signature generation step E63 during which the server generates a second signature data Sm by signing the masked encryption token received at the same time. using his signature private key skSign. We then have: Sm = Sign (C ^ a, skSign).
[0042] The step of generating an E6 signature token may then comprise a second E64 token transmission step in which the server transmits the second signature data Sm to the client.
[0043] According to a first variant, the client device then obtains a signature token S by unmasking the second signature data Sm with the second mask data item a and stores the unmasked signature token S = Sign (C, skSign) in memory. In a second variant, the client device stores in memory 15 the second signature data Sm and the second mask data a. The client device is then able, when necessary, to unmask the second signature data Sm to obtain the unmasked signature token S.
[0044] According to a second embodiment shown in FIG. 5, the enrollment of the client device is carried out with a trusted enrollment server that can take cognizance of the secret element chosen by the client. The step of determining the secret element E4 then comprises the selection of the secret element by a customer holding the client device and the transmission of the selected secret element to the server, in masked or encrypted form, and the steps of generation of the E5 token and E6 signature tokens comprise the generation of the encryption token and signature token by the server and the transmission of these tokens to the client device.
[0045] More specifically, the step of generating the encryption token E5 may comprise a first step of calculating a hash E51 and a first encryption step E52 similar to those described above in the first embodiment but implemented. implemented by the enrollment server. Alternatively, in the first encryption step E52, the encryption token generated by the enrollment server may depend on a secret key k of the enrollment server. For example, the encryption token may be equal to C = Enc (g ^ (P * k)). Optionally, such a key may depend on the identity of the client. The step of generating the encryption token E5 may also include a third token transmission step E53 in which the server transmits to the client device the encryption token generated during the first encryption step E52. According to an alternative, the transmitted encryption token may be accompanied by an additional element C2 depending on the secret key k of the enrollment server. For example, this additional element may be equal to C2 = Enc2 (g ^ k), Enc2 being an encryption algorithm using an encryption key possibly different from that used by the algorithm Enc. The step of generating a signature token E6 may comprise a second signature generation step E65 during which the server generates a signature token S by signing the encryption token C generated during the generation step. the E5 crypto token using its skSign signature private key. We then have: S = Sign (C, skSign). The step of generating an E6 signature token may then comprise a fourth token transmission step E66 in which the server transmits the generated signature token S to the client.
[0046] In a third embodiment shown in FIG. 6, the step of generating the encryption token E5 can comprise the generation by the server of a temporary secret element, the generation of a temporary encryption token from the temporary secret element, the transmission of the temporary secret element and the temporary encryption token to the client device and the generation by the client device of an encryption token from the temporary encryption token, the temporary secret element and the secret element (PIN) chosen by the client during the step of determining the secret element E4. In addition, the step of generating the signature token E6 may include the generation by the server of a temporary signing token by signing the temporary encryption token, the transmission of the temporary signing token to the client device and the generation by the client device of a signature token from the temporary signing token, the temporary secret element and the secret element (PIN). The client device can thereby generate its own encryption and signature tokens corresponding to its PIN secret element from the temporary tokens transmitted by the server. More specifically, the step of generating the encryption token E5 may include a temporary secret element generation step E54 during which the server generates a temporary secret element PlNtemp, for example random. The step of generating the encryption token E5 may then comprise a first step of temporary token generation E55 during which the server generates a temporary encryption token Ctemp from the temporary secret element PlNtemp, and optionally of an additional secret element as described above. For this, the server can generate a hash Ptemp = h (s, PlNtemp) from the temporary secret element PlNtemp similarly to the hash calculation implemented during the first step of calculating a hash E51 described herein. above, and then the server may generate the encryption token Ctemp = Enc (gAPtemp, pkEnc) from the hash computed in a manner similar to the generation of encryption token implemented in the first encryption step E52 described above. above. The step of generating the encryption token E5 may then comprise a fifth token transmission step E56 in which the server transmits the temporary secret element PlNtemp and the temporary encryption token Ctemp to the client device. The step of generating the encryption token E5 may finally comprise a first token derivation step E57 during which the client device derives an encryption token C corresponding to its secret element PIN from the temporary encryption token Ctemp, the temporary secret element PlNtemp and the secret element PIN chosen by the client during the step of determining the secret element E4. Thanks to the homomorphism property of the encryption function Enc, the client device can indeed replace the temporary secret element PlNtemp by the secret element PIN in the encryption token Ctemp 10. As an example we have: C = CtempA (P / Ptemp) = (Enc (gAPtemp, pkEnc)) A (P / Ptemp) = Enc ((gAPtemp) ^ (P / Ptemp), pkEnc) = Enc (gAP , pkEnc). The step of generating the signature token E6 may include a second temporary token generation step E67 during which the server generates a temporary signature token Stemp from the temporary encryption token Ctemp. For this, the server can sign the temporary encryption token using its signature private key skSign to generate a temporary signature token Stemp = Sign (Ctemp, skSign) in a manner similar to the generation of signature token implemented during the second signature generation step E65 described above. The step of generating the signature token E6 may then comprise a sixth token transmission step E68 during which the server transmits the temporary signature token Stemp to the client device. The step of generating the signature token E6 may finally comprise a second token derivation step E69 in which the client device derives a signature token S corresponding to its secret element PIN from the temporary signature token Stemp. the temporary secret element PlNtemp and the secret element PIN chosen by the client during the step of determining the secret element E4. Thanks to the property of homomorphism of the signature function Sign, the client device can indeed replace the temporary secret element 3027177 28 by the PIN secret element in the signature chip Stemp Indeed we have: S = StempA ( P / Ptemp) = (Sign (Ctemp, skSign)) ^ (P / Ptemp) = Sign ((Ctemp) ^ (P / Ptemp), skSign) = Sign (C, skSign).
[0047] At the end of the enrollment phase, after the implementation of the steps of generation of the encryption token E5 and generation of the signature token E6, the client device can have an encryption token C corresponding to the result encrypting its secret element PIN with a pseudo-homomorphic encryption function Enc as well as a signature token S corresponding to the result of the signing by the enrollment server of the encryption token C to using a signature pseudo-homomorphic signature function, or a second signature data Sm and a second mask datum a allowing it to generate the signature token S. The client device can check the validity of signing the signature token S or the second signature data Sm received using the public signature key pkSign transmitted by the server.
[0048] Authentication phase The method according to the invention can then be continued by an authentication phase of the client device with the authentication server.
[0049] According to a first variant described in FIG. 7, the knowledge proof generation step A1 may comprise a challenge transmission step E7 during which the server transmits a challenge r to the client device. According to a second variant, described in FIG. 8, the knowledge proof generation step A1 can comprise a message determination step E7 during which the client device determines a message r based on the identity of the client and 3027177 29 of a timestamp. The client device may also determine an authentication counter. According to a third variant, described in FIG. 9, the knowledge proof generation step A1 may comprise a challenge transmission and message determination step E7 during which the server transmits a challenge d to the client device and the client device determines a message r from the received challenge, the client identity, and a time stamp. The authentication phase may then comprise a third signature generation step E8 during which the client device generates a signature data Z by signing the challenge or message r with the aid of a masked proof generation key. a non-public random data item known only from the client device, called the first mask data item 3, said masked key making it possible to prove the knowledge of the PIN secret element without disclosing it. By way of example, the client device generates the signature data Z by signing the challenge or message r with a masked proof generation key P * 8 according to the formula Z = signature (r, P * 8). To generate this signature data, the client device must have access to the value of the secret element 20 to generate the masked proof generation key. The customer holding the client device can at this time enter the PIN secret element on the client device. The client device can, after a first input by the client, temporarily store in memory the value of the secret element or its encrypted, for example for the duration of a session in progress. For example, the signature algorithm used to generate the Z signature data is of the DSA, ECDSA or Schnorr type. The first transmission step A2 may then comprise a signature data transmission step E9 during which the client device transmits the signature data Z to the server.
[0050] The second transmission step A3 may comprise a seventh token transmission step El 0 in which the client device transmits to the server its masked C encryption token using the first mask data R. The device client for example transmits the CAP data. Thanks to the homomorphism property of the encryption function, this masked encryption token corresponds to the result of the encryption by the encryption function Enc of the hash P of the secret element PIN masked with the aid of the first mask data R For example: CAP = (Enc (gAP, pkEnc)) ^ 13 = Enc ((g ^ 13) ^ 13, pkEnc) = Enc (g ^ (P * 13), pkEnc). The second transmission step A3 may also comprise an eighth token transmission step El 1 during which the client device transmits to the server its masked signature token S using the first mask data R. The client device transmits for example the SA data [3. By virtue of the homomorphism property of the signature function, this masked signature token corresponds to the result of the signing by the signature function Sign of the masked encryption token C using the first mask data R. example: SA13 = (Sign (C, skSign)) ^ 13 = Sign (CAR, skSign).
[0051] Alternatively, if the encryption token C transmitted is dependent on a secret key of the enrollment server, for example C = Enc (g ^ (P * k)), the client device transmits in the eighth transmission step of token El 1 the value gA (P * 13). The first verification step A4 may comprise a third verification step E12 in which the server verifies the validity of the signature of the masked signature token SA13 received from the masked encryption token received CAP. The server can thus verify that the client device has an encryption token and the corresponding signature token generated using the private key pkSign of the sign signature function, known only to the server. Thanks to the masking by the first mask data item 3, this verification is performed without disclosing the encryption token C and the signature token S of the client device, thus preventing this data from being intercepted and reused by an attacker. Alternatively, if the encryption token C transmitted is dependent on a secret key of the enrollment server 5, the server performs in the third verification step E12 a consistency check by calculating the value (g ^ (P * 6) ) ^ k = gA (Pirk) and verifying that it is equal to the result of decrypting the received masked encryption token CAR. The second verification step A6 may include a fourth verification step E14 in which the server verifies the validity of the signature of the received signature data (Z = signature (r, (P * 6)) using In a first variant, the proof verification key may be the masked authentication token itself.In a second variant, the proof verification key is associated with the key of verification. For example, the proof verification key may be the public key corresponding to the private key generation key P * 6 in a public key / private key signature scheme, for example, the proof verification key. Alternatively, the proof verification key may be equal to gA (Pirk) if the transmitted token is dependent on a secret key of the enrollment server. then understand generating a decryption step E13 in which the server decrypts the masked encryption token CAp = Enc (g ^ (P * 6)), alternatively CAp = 25 Enc (g ^ (Pirk)) using the function pseudohomomorphic encoding Enc so as to obtain the proof verification key gA (P * 6), alternatively gA (Pirk). The server can thus ensure that the client is aware of the secret element used to generate the encryption token that has been provided to it in masked form. This verification can take place without the secret element nor the masked key being disclosed or known to the server. In the case where the encryption and signature keys used to generate the C and S signature tokens depend on the identity of the user, the server must use the keys corresponding to the identity of the client to implement performs the signature verification during the third verification step E12 and the decryption during the decryption step E13. This allows the server, for example, to verify that the encryption token provided to it corresponds to the client that supplied it, that is to say that this encryption token has been generated with the key corresponding to it. client, otherwise the decryption of this token results in a failure. Similarly, in the case where the generator g is specific to a given client device, the server must use the generator 15 corresponding to the identity of the client to implement the signature verification in the fourth verification step E14. The customer's identity may have been transmitted to him by the client device, either automatically or following an entry of an identifier by the customer holding the client device. Alternatively, the server does not know the identity of the client and attempts to implement the third verification step E12 and the decryption step E13 with its various keys until these operations are successful or has exhausted all the keys at his disposal. 2nd implementation mode in which the authentication token is generated using homomorphic MACs on elliptic curves: According to a second authentication token generation implementation, the authentication token J can be generated in a single block using a pseudo-homomorphic symmetric MAC algorithm.
[0052] Initialization phase The server can determine a pseudo-random number generator PRG of a set KG in the set Zp2, and a pseudo-random function PRF of KF x <G> in the set Zp, G being a group of first order p of generator g. The enrollment server can also derive an element K = (K1, K2) belonging to KG x KF, binary random sets. A security parameter A, non-zero integer, can also be defined, such as Ipl = 2 ^ A. For example A = 128, 256, 512 or more. Enrollment Phase The method can then be followed by an enrollment phase of the client device with the enrollment server during which the client device obtains the authentication token J. This phase may include a step of determining the authentication token. a PIN secret element by the client device E4 and a step of generating an authentication token J. The step of determining the secret element E4 comprises the selection of the secret element by a client holding the device customer.
[0053] The step of generating an authentication token J may comprise a hash calculation step P identical to the first step of calculating an E51 hash described above. The step of generating an authentication token J may then comprise steps of: calculating the values X1 = g ^ (P * a) and X2 = g ^ a, a being a second mask datum known only to the client device, - transmission of the calculated values X1 and X2 to the enrollment server, 5 - pulling by the server of an element R in the group G, possibly depending on the identity of the client device, - calculation by the u = u2 server) = PRG (K1), b = PRF (K2, R), - calculation by the server of a masked authentication token T '= Xl Aui * X2A (u2 + b), 10 - transmission by the server of the masked authentication token T 'and of the element R to the client device, - determination by the client device of the authentication token J from the masked authentication token T' by raising it to the power lia, 15 - storage by the client device of the authentication token J. Authentication phase The method according to the invention can then be follow through an authentication phase of the client device with the authentication server. The step of generating a proof of knowledge of the secret element Al comprises the generation by the client device of a signature data Z obtained by signing a challenge r E {0,1} ^ to transmitted by the server using a masked proof generation key with a first mask data R. Such a masked proof generation key is for example equal to P * 13. To generate this signature data, the client device must have access to the value of the secret element to generate the masked evidence generation key. The client holding the client device can at this point enter the PIN secret element on the client device. The client device can, after a first input by the client, temporarily store in memory the value of the secret element or its encrypted, for example for the duration of a session in progress. The signature used may be a signature obtained by implementing the Schnorr algorithm. The proof of knowledge generated, that is, the signature data Z is then transmitted during the proof transmission step A2 of the client device to the server. The second transmission step A3 may comprise a transmission step during which the client device calculates the value Y2 = g ^ 3 and transmits to the server the calculated value Y2 as well as the masked authentication token J '= J ^ 13 and a masked CT control value, in the form CTA13 = Enc (g ^ (P * 13)) or CTA13 = gA (P * 13). The value gAP or the corresponding encipher Enc (g ^ (P)), necessary for the calculation of the masked control value, can be stored by the client device from the enrollment phase, or be determined on the fly from the value of the secret element entered by the client at the beginning of the authentication phase. The first verification step A4 may include a verification step during which the server verifies the validity of the received authentication token zo token J '. For this, the server can obtain gA (P * 13) from the masked control value, if necessary by deciphering it, calculate u = u2) = PRG (K1), calculate B = Y2A (PRF (K2, R) ), calculate D = (g ^ (P * 13)) Aui * Y2Au2, and check if B * D is equal to JA13. The step of obtaining an A5 verification key may include obtaining a verification key associated with the proof generation key. The verification key may for example be the public key corresponding to the private key P * 13 in a public key / private key signature scheme. For example, in the case of using the Schnorr algorithm for signing, the proof verification key may be 30 gA (p * F3). Finally, the second verification step A6 may comprise a verification step at during which the server verifies the validity of the signature of the received signature data (Z = signature (r, (P * 13)) using the proof verification key obtained. which the authentication token is generated using a Diffie Hellman algorithm on elliptic curves (first variant): Initialization phase In this phase, the enrollment server defines a security parameter λ, It also determines an elliptic curve (p, G, g), with p a prime number, order of the group G of the points of the curve, such that 'pl = 2 ^ A, and g being a generator of group G. Enlistment phase This phase may include a step of determining secret element by the client device E4 and a step of generating an authentication token J. The step of determining the secret element E4 comprises the selection of the secret element by a client holding the secret element E4. client device.
[0054] The step of generating an authentication token J may comprise a hash calculation step P identical to the first step of calculating an E51 hash described above. The step of generating an authentication token J may then comprise steps of: computing by the client device of a value Y = g ^ (P * a), where a is a known mask datum only the client device; transmitting said Y value to the server; - derivation of a user key k E Zp * by the server; 5 - calculation by the server of a masked authentication token T '= yAk; transmission of the masked authentication token T 'to the client device; determination by the client device of the authentication token J from the masked authentication token T 'received by raising it to the power a "(- 1) mod p - storage by the client device of a token d authentication J. Authentication phase 15 The step of generating a proof of knowledge of the secret element Al comprises the generation by the client device of a signature data Z obtained by signing a challenge r E {0, 1} ^ A transmitted by the server using a masked proof generation key with a first mask data item P. Such a masked proof generation key is for example equal to P * 13. As a signature data item, the client device must have access to the value of the secret element to generate the masked proof generation key The client holding the client device may at this point enter the PIN secret element on the client device. The client device can, following at a first input by the client, temporarily store in memory the value of the secret element or its encrypted, for example for the duration of a session in progress. The signature used may be a signature obtained by implementing the Schnorr or ECDSA algorithm, the secret keys to be in Zp *.
[0055] The proof of knowledge generated, that is, the signature data Z, is then transmitted during the proof transmission step A2 of the client device to the server. The second transmission step A3 may comprise a transmission step during which the client device calculates and transmits to the server the masked authentication token J '= JA8 and a masked CT control value, in the form CTA8 = Enc ( g ^ (P * 8)) or CTA8 = gA (P * 8). The value gAP or the corresponding encipher Enc (g ^ (P)), necessary for the calculation of the masked control value, can be stored by the client device from the enrollment phase, or be determined on the fly from the value of the secret element entered by the client at the beginning of the authentication phase. The first verification step A4 may comprise a verification step during which the server verifies the validity of the masked authentication token I received. For this, the server can obtain gA (P * 8) from the masked control value, if necessary by decrypting it, obtain the derived user key k and check if (g ^ (P * 8)) ^ k is equal to JA13. The step of obtaining an A5 verification key may include obtaining a verification key associated with the proof generation key. The verification key may for example be the public key corresponding to the private key P * 8 in a public key / private key signature scheme. For example, the proof verification key can be computed from g ^ (k * P * 8), ie from the masked authentication token itself. The second verification step A6 may comprise a verification step during which the server verifies the validity of the signature of the received signature data (Z = signature (r, (P * 8)) using the key The third mode of implementation in which the authentication token is generated using a Diffie Hellman algorithm on elliptic curves (Second variant): Initialization phase In this phase, the enrollment server defines a security parameter λ, which is a non-zero integer, and determines an elliptic curve (p, G, g) with p a prime number, order of the group G of the points of the curve, such that ## EQU1 ## and g being a generator of the group G. Enrollment phase This phase may comprise a step of determining a secret element by the client device E4 and a step of generating a token of authentication J. The element determination step secret E4 includes the selection of the secret element by a customer holding the client device.
[0056] The step of generating an authentication token J may comprise a hash calculation step P identical to the first step of calculating an E51 hash described above. The step of generating an authentication token J can then comprise steps of: calculation by the client device of a value Y equal to gA (P * a), where a is a mask datum known only from the client device; transmitting said Y value to the enrollment server; 30 - derivation of a user key k E Zp * by the server and storage of this key by the server in the form K = g ^ k; 3027177 - calculation by the server of a masked server token T '= YAk; transmission of the masked server token T 'to the client device; the client device determines the authentication token J from the masked server token T 'received by raising it to the power a "(- 1) mod p - storage by the client device of a token of authentication J. Authentication phase 10 The step of generating a proof of knowledge of the secret element Al comprises the generation by the client device of a signature data Z obtained by signing a challenge r E {0,1 It is transmitted by the server with a masked proof generation key with a first mask data R. Such a masked proof generation key is, for example, equal to P * 13. To generate this signature data, the device client must have access to the value of the secret element to generate the masked proof generation key The client holding the client device can at this point enter the PIN secret element on the client device The signature used can be a signature obt issued using the Schnorr or ECDSA algorithm, the secret keys to be in Zp *. The proof of knowledge generated, that is, the signature data Z is then transmitted during the proof transmission step A2 of the client device to the server.
[0057] The server can also recover the value K = g ^ k stored during the enrollment phase, draw b in Zp *, calculate K '= KID and transmit K' to the client device. The second transmission step A3 may comprise a transmission step during which the client device calculates and transmits to the server a value K "= K '^ (P * 13) and the masked authentication token s = JAIS.
[0058] The first verification step A4 may comprise a verification step during which the server verifies the validity of the masked authentication token J 'received. For this, the server can check if (jAp) Ab = -A g (P * eirb) is equal to K ".
[0059] The step of obtaining an A5 verification key may include obtaining a verification key associated with the proof generation key. The verification key may for example be the public key corresponding to the private key P * 8 in a public key / private key signature scheme. For example, the proof verification key can be computed from gA (P * 8 * k), that is, from the masked authentication token itself. The second verification step A6 may comprise a verification step during which the server verifies the validity of the signature of the received signature data (Z = signature (r, (P * 8)) using the key The fourth implementation mode in which the authentication token is generated based on RSA signature: Initialization phase The enrollment server defines a non-zero integer security parameter defining the the size of the cryptographic objects to be used, it then selects (N, e, d) according to λ, with N product of two first safe integers and the inverse of e modulo N, then a bit string r containing information specific to the user and calculates R equal to HQ (r) with HQ an application of {0, 1} * in a group G of generator G. For example, if A = 100, N is chosen of size 2048 bits. The server then passes N, e, and R to the client device.
[0060] This phase comprises a step of determining a secret element by the client device E4 and a step of generating an authentication token J.
[0061] The step of determining the secret element E4 may include the selection of the secret element by a client holding the client device. The step of generating an authentication token J may comprise a hash calculation step P identical to the first step of calculating an E51 hash described above. The step of generating an authentication token J may then comprise steps of: calculation and transmission by the client device to the enrollment server of a value H 'equal to gA (P * a), a being a mask data known only from the client device and a value R 'equal to R masked with the mask data a: R' = RAa; calculation and transmission by the server to the client device of a masked server token S 'equal to (R'.H') Ad mod N. - determination by the client device of a server token S from the masked server token Received by raising it to the power 11a. storage by the client device of an authentication token J = (R, S), as well as N and e values.
[0062] Authentication phase The step of generating a proof of knowledge of the secret element Al comprises the generation by the client device of a signature data item Z obtained by signing a challenge r E {0,1} Transmitted by the server with a masked proof generation key with a first mask data R. Such a masked proof generation key is for example equal to P * 13. To generate this signature data, the client device must have access to the value of the secret element to generate the masked evidence generation key. The customer holding the client device can at this point enter the PIN secret element on the client device. The signature used may be a signature obtained by implementing any signature algorithm compatible with G. The proof of knowledge generated, that is to say the signature data Z, is then transmitted during the step of A2 proof transmission from the client device to the server. The second transmission step A3 may comprise a transmission step during which the client device transmits to the server the masked authentication token J '= J ^ 13 = ((R "13, SA13) and a HA value 13 = The first verification step A4 may comprise a verification step during which the server verifies the validity of the masked authentication token J 'received. the server can check if (SA13) Ae = (RA (13 * Ce)) * gA (P * 13 * Ce) equals RA13.HA13 mod N.
[0063] The step of obtaining an A5 verification key may comprise obtaining a verification key associated with the proof generation key. The verification key may for example be the public key corresponding to the private key P * 13 in a public key / private key signature scheme. For example, the proof verification key can be calculated from HAPS = gA (P * 13). The second verification step A6 may include a verification step during which the server verifies the validity of the signature of the received signature data (Z = signature (r, (P * 13)) using the key verification method obtained from the received masked authentication token 30 5th mode of implementation in which the authentication token is generated based on pseudohomomorphic double encryption on elliptic curves. Enrollment defines a security parameter λ, nonzero integer, and determines an elliptic curve (p, <G>, G) with p 10 a prime number such that 'p1 = 2 ^ λ p is the order of the group <G> points of the generator curve G. The server also determines a quadruplet of keys (u, y, U, V) belonging to Zp x Zp x <G> x <G> such that U = [u] * G and V = [v] * G, with [u] and [y] integers modulo p in Zp, U is a first public key It is associated with a first secret private key [u] of a first asymmetric pseudohomomorphic encryption function Encl of the type of El Gamal algorithm. V corresponds to a second public key associated with a second secret private key [y] of a second asymmetric pseudohomomorphic encryption function Enc2 of the El Gamal algorithm type. The secret keys [u] and [y] may be different or identical. The first and second functions may be different or the same. These encryption keys will be used to generate the different tokens that the client device will need to authenticate during a subsequent authentication phase.
[0064] Enrollment Phase This phase may comprise a step of determining a secret element by the client device E4 and a step of generating an authentication token J.
[0065] The step of determining the secret element E4 comprises the selection of the secret element by a client holding the client device. The step of generating an authentication token J may comprise a hash calculation step P identical to the first step of calculating an E51 hash described above. The step of generating an authentication token J may then comprise steps of: calculation by the client device of a value Y equal to [P * a] * G, where a 10 is a known mask data only the client device; transmitting said Y value to the enrollment server; - derivation of a secret user key k E Zp * by the server; calculation by the server of a first encrypted token (U1, U2), result of an encryption by the first pseudo-homomorphic asymmetric encryption function Enc1 of the secret user key k with the first public key U associated with the first secret private key u. For example, U1 = U2 = [k] * G + [ri] * G, with r1 determined by the server and belonging to 20 Zp; calculating a masked server token (V1 ", V2") resulting from an encryption by the second asymmetric pseudohomomorphic encryption function Enc2, with the second public key V associated with the second secret private key y, of the secret key user k and the proof generation key P masked by the mask data a. The masked server token can thus correspond to the result of Enc2 encryption of the product [kPa] * G with the second public key V. For example, V1 "= [r2TV and V2" = [k] * Y + [r2l * G with r2 'determined by the server and belonging to Zp; - transmission of the first encrypted token (U1, U2) and the masked server token (V1 ", V2") to the client device; optionally, storage by the server of H1 (K), H1 being a hash function chosen by the server and K being equal to 5 [k] * G; - determination by the client of the authentication token (V1, V2) from the masked server token (V1 ", V2") received by multiplying it by a factor a ^ (- 1) mod p, - storage by the client device the first encrypted token (U1, U2) and the authentication token J. At the end of this enrollment phase, the client device can have a first encrypted token and an authentication token, corresponding respectively to the numbers of k and kP. These tokens 15 encrypted with the public keys U and V can only be decrypted by the server, the sole holder of the associated private keys u and y. During a subsequent authentication phase, the client device can thus use these tokens to prove to the server its knowledge of the secret element PIN without disclosing it and to prove that the two tokens have been generated from the same user key k. Authentication phase The step of generating a proof of knowledge of the secret element Al comprises the transmission of a challenge r E {0,1} ^ A by the server to the client device and the generation by the device client of a signature data Z obtained, for example according to a Schnorr signature algorithm, from a first parameter t, a first value of hash c and a masked proof generation key with a first 30 mask data p. Such a masked proof generation key is for example equal to P * 6. To generate this signature data, the client device must have access to the value of the secret element to generate the masked evidence generation key. The customer holding the client device can at this time enter the PIN secret element on the client device. Said first hash value c is obtained from the received challenge r, the first encrypted token (U1, U2), the masked authentication token J 'with the aid of the first mask data [3 and a second encrypted token (R1, R2). The signature data Z may for example be determined in a step F8 by the client device by implementing the following steps: optionally, determining F80 of a first random encrypted token (U1 ', U2') by applying a random to the first encrypted token (U1, U2). For example U1 '= U1 + [rr] * U and U2' = U2 + [rr] * G, with [rr] a randomly chosen scalar belonging to Zp *; The application of such a hazard to the result of a probabilistic encryption makes it possible not to be able to trace an initial datum that has been the subject of encryption and the application of the hazard since the results of the encryption and the application of the hazard will be different for the same initial data. If this step is not performed, the first encrypted token (U1, U2) is equal to the first random encrypted token (U1 ', U2') in the following description. F81 calculation of the second encrypted token (R1, R2) corresponding to the encryption by the first pseudo-homomorphic asymmetric encryption function Enc1 of the secret user key k and a first parameter t drawn in Zp * by the client device with the first public key U associated with the first secret private key u. The second encrypted token may correspond to the encryption of [t k] * G. The second encrypted token is computed from the first random encrypted token (U1 ', U2') and the first parameter t. For example: R1 = [t] * U1 'and R2 = [t] * U2', 3027177 48 - F82 calculation of the masked authentication token obtained by hiding the authentication token (V1, V2) with the aid of the first mask data [3: J '= (V1', V2 ') with V1' = [[3] * V1 and V2 '= [[3] * V2 5 - F83 calculation of a first value of hash c from the challenge r, the first random encrypted token (U1 ', U2'), the masked authentication token J 'and the second encrypted token (R1, R2). For example, such a first hash value c may be equal to H2 (U1'11U2'11V1'11V2'11R1I1R211r), where H2 is a hash function of {0,1} * in {0,1} ^ A, the sign "II" representing the concatenation operation, - calculation F84 of the signature data Z from the first parameter t, the first value of hash c and the masked proof generation key using the first mask data 13: P * 13. For example Z can be equal to t + c * P * 13 mod p. The proof of knowledge generated, that is, the signature data Z is then transmitted F9 during the proof transmission step A2 of the client device to the server.
[0066] The second transmission step A3 may comprise a transmission step F10 in which the client device transmits the masked authentication token to the server using the first mask data 3: J '= (V1', V2 The client device also transmits in a step F11 to the server the first random encrypted token (U1 ', U2'), as well as the second encrypted token (R1, R2). The server then simultaneously implements an A4 check of the validity of the masked authentication token I received and an A6 check of the validity of the proof of knowledge Z from the received masked authentication token. For this purpose, the server can implement the following steps: - computation F12 of a second value of hash c 'from the challenge r, of the first random encrypted token (U1', U2 '), of the token of Masked authentication using the first mask data [3: J 'and the second encrypted token (R1, R2) received. For example, such a first hash value c may be equal to H2 (U1'11U2'11V1'11V2'11R1I1R211r) - F13 calculation of a first deciphered token K 'by deciphering the first random encrypted token (U1', U2 ' ) with the first secret private key u of the first pseudo-homomorphic asymmetric encryption function. For example, such a first decrypted token K 'may be equal to U2' - [u *] * U1 ', with u * = u-1 mod p; The first decrypted token K 'can then be a function of [k] * G, - calculation F14 of a proof verification key T' by deciphering the masked authentication token (V1 ', V2') with the second key secret private v of the second pseudo-homomorphic asymmetric encryption function Enc2; For example, the second deciphered token T 'may be equal to V2' - [v *] * V1 ', with v * = v-1 mod p; The second decrypted token T 'can then be a function of [k [3 P] * G - F15 calculation of a second deciphered token R by deciphering the second encrypted token (R1, R2) with the first secret private key u of the first pseudo-homomorphic asymmetric encryption function Enc1; For example, the third decrypted token R may be R2 - [u *] * R1; The third decrypted token R can then be a function of [tk] * G, - check F16 by the server of the validity of the masked authentication token received and the proof of knowledge from the received signature data Z, of the first token decrypted K ', second deciphered token R, second hash value c' and proof verification key T 'by 3027177 example by checking the following equality: Z * K' = R + [c '] * T'. This check enables the server to determine the validity of the masked authentication token using the first mask data [3 received] and the validity of the proof of knowledge Z. The client device thus proved to the server that knowledge of the PIN secret element without disclosing it. In addition, by checking this equality, the server ensures that the tokens have been generated from the same user key k.
[0067] The server may also perform an additional check by testing whether H (K ') is equal to H (K). Such an additional check verifies that the secret user key k used to generate the tokens provided by the client device during its authentication is the same as that memorized by the server for this client during his enrollment. Once the authentication of the client device is successful, session keys such as encryption keys and MAC integrity keys can be generated and shared between the client device and the server, and then used as valid keys to secure the exchanges. between the client device and the server, for example until the expiration of a current session. For example, these keys can be derived from the verification key gA (P * 13), used as shared secret between the client device and the server.
[0068] It is possible to provide a mechanism for recovering the hash P of the secret element PIN to find this hash if the PIN is forgotten by the customer holding the client device. Since the secret element is not known to the server, it can not send it back to the client. One solution is that the client device stores a value y said secret element complement, such that the value y + P is easily attackable, for example by a brute dictionary attack, i.e. that the server can find y + P from g ^ (y + P). When the client device wishes to retrieve the hash of its secret element, it then suffices to generate (gAp) * (gAy) = gA (y ± r) and to transmit it to the server, which then regains the value of y + P and retransmits it to the client device so that it regains the value of P since it knows that of y It is also possible to provide a mechanism for modifying the secret element by the client device. Signature and encryption can then be generated from a new secret element chosen by the client according to the third generation mode described above, using temporary tokens generated by the server.
[0069] Thus, the customer holding the client device can prove to the server his knowledge of the PIN secret element, without this secret element being stored in the memory of the client device or the server, rendering the process insensitive to a compromise of the memory of the client. client or server device. In addition, the data exchanged between the client device and the server may be masked by masking data, making it difficult for them to reuse by an attacker and protecting the process against replay attacks. Finally, no complex calculation is necessary, thus limiting the necessary computing power and making it possible to implement it on a thin client such as a mobile phone. 25

权利要求:
Claims (32)
[0001]
REVENDICATIONS1. A method of authenticating a client device to a server using a secret element (PIN), said client device holding an authentication token (J) generated using a pseudo-function homomorphic and from said secret element (PIN), said method comprising steps of: - generating (A1), by the client device, a proof of knowledge of the secret element (PIN) from a key of masked proof generation (P) with a first mask datum (p), said first mask datum being a non-public random datum known only to the client device and said masked proof generation key (P) being constructed so as to prove the knowledge of said secret element (PIN) without disclosing it, - transmission (A2), to the server, by the client device of said proof of knowledge of the secret element generated, - transmission (A3) to the server by the client device of the token to authenticate fication (J) masked using the first mask data item (p), - verification (A4) by the server of the validity of the masked authentication token received, - verification (A6) by the server of the validity of the proof of knowledge.
[0002]
2. Authentication method according to the preceding claim, comprising a step of obtaining (A5) by the server of a proof verification key associated with said proof generation key, and wherein the verification step (A6 ) of the validity of the proof of knowledge includes a check by the server 3027177 53 of the validity of the proof of knowledge using the verification key obtained evidence.
[0003]
3. Authentication method according to one of the preceding claims wherein the server verifies the validity of the proof of knowledge (A6) from the received masked authentication token.
[0004]
4. Authentication method according to one of the preceding claims, wherein the authentication token (J) comprises an encryption token (C) obtained by encryption from said secret element (PIN) with the aid of a pseudohomomorphic encryption function (Enc). 15
[0005]
5. Authentication method according to the preceding claim, wherein: the authentication token (J) further comprises a signature token (S) corresponding to the result of the signing of the encryption token (C) using of a pseudo-homomorphic signature function (Sign), the step of transmitting the masked authentication token (J) (A3) comprises the transmission (E10), by the client device, to the server, of the token of masked held encryption (CA 3) using the first mask data (13) and the transmission (E11) by the client device to the server of the masked signature token (Sign (C) ^ 3) using the first mask data (p); the masked authentication token verification step (A4) comprises the verification (E12) by the server of the validity of the signature of the masked signature token received from the received masked encryption token. 3027177 54
[0006]
6. Authentication method according to one of the preceding claims wherein: - the generation step (A1) of a proof of knowledge of the secret element (PIN) comprises the transmission of a challenge 5 ("challenge"); ) (R) (E7) by the server to the client device, and the generation (E8), by the client device, of a signature data item (Z) obtained by signing the challenge (r) received with the aid of said masked proof generation key (P), - the step of transmission (A2) to the server by the client device of said secret element knowledge proof comprises the transmission (E9), by the client device, of said signature data (Z) to the server.
[0007]
7. The authentication method according to one of claims 4 to 6 wherein: the step of transmission (A3) of the masked authentication token (J) comprises the transmission (E10), by the client device, to server, the cached held encryption token (CA 3) using the first mask data (p), 20 - the obtaining step (A5) of the proof verification key from the token of received masked authentication includes decrypting (E13), by the server, the masked encryption token received with the pseudo-homomorphic encryption function to obtain a proof verification key, - the verification step (A6) of the validity of the proof of knowledge includes checking (E14), by the server, of the validity of the signature of the received signature data (Z) using the obtained proof verification key. 3027177 55
[0008]
8. Authentication method according to one of claims 5 or 7 further comprising during a prior enrollment phase steps of: -determination (E4) of the secret element by the client device and, 5 -generation encryption (E5) and signature (E6) tokens.
[0009]
9. Authentication method according to claim 8 wherein, during the enrollment phase, the step of determining the secret element (E4) comprises the selection of the secret element by a customer holding the client device and the step of generating the encryption token (E5) comprises generating the encryption token by the client device;
[0010]
10. The authentication method according to claim 8 wherein, during the enrollment phase, the step of determining the secret element (E4) comprises selecting the secret element by a customer holding the client device. and transmitting the selected secret element to the server, and the steps of generating the encryption (E5) and signature (E6) tokens include the generation of the encryption token and the signature token by the server and the transmission ( E53, E66) of these tokens to the client device.
[0011]
11. Authentication method according to one of claims 8 to 10, wherein the step of generating an encryption token (E5) 25 comprises the calculation (E51) of a hash of the secret element from a hash function and the encryption (E52) of said hash using the pseudo-homomorphic encryption function (Enc).
[0012]
12.The authentication method according to claim 8 wherein, the step of generating the encryption token (E5) comprises the generation by the server of a temporary secret element (E54), the generation of a token temporary encryption (E55) from the temporary secret element, transmission of the temporary secret element and the temporary encryption token to the client device (E56) and generation by the client device of an encryption token ( E57) from the temporary encryption token, the temporary secret element and the secret element (PIN), and wherein the step of generating the signature token (E6) comprises the generation by the server of a temporary signature token (E67) by signing the temporary encryption token, the transmission of the temporary signature token (E68) to the client device and the generation by the client device of a signature token (E69) from the token of signat the temporary secret element and the secret element (PIN). 15
[0013]
The authentication method of claim 12, wherein generating the temporary encryption token (E55) comprises computing a hash of the temporary secret element from a hash function and encrypting said hash to using the pseudo-homomorphic encryption function (Enc). 20
[0014]
14. Authentication method according to one of claims 11 or 13, wherein the step of calculating a hash of a secret element comprises the calculation of a hash of said secret element and at least one secret element additional from a hash function. 25
[0015]
15.The authentication method according to claim 11 or 13, wherein the generation of an encryption token from a secret element a is performed using the following formula: C = Enc (gAP) with g a generator of a high order group and P = h (s, a) with a random number (salt), a hash function and a may be equal to the secret element (PIN) or to a temporary secret element.
[0016]
16. Authentication method according to one of claims 8, 9, 11, 14, 15 wherein, during the enrollment phase: - the step of generating the encryption token (E5) is performed by the client device, - and the step of generating the signature token (E6) comprises: - the masking (E61) of said encryption token using a second random mask datum a and known only to the client device, the transmission (E62) to the server of said masked encryption token; the generation (E63) by the server of a second signature data item (Sm) by signing the masked encryption token received using the function of pseudo-homomorphic signature (Sign), - the transmission (E64) by the server of the second signature data to the client device, said signature token being obtained from said second signature data using the second data of mask.
[0017]
17. The authentication method according to the preceding claim, wherein said client device verifies the validity of the signature of said second signature data.
[0018]
18. The authentication method according to one of claims 4 to 17, wherein the encryption and signature functions are asymmetric functions. 3027177 58
[0019]
19. Authentication method according to the preceding claim, comprising during an initialization phase the implementation by the server of the steps of: - generation (El) of a pair of asymmetric signature keys 5 (pkSign, skSign ) to implement the pseudo-homomorphic signature function (Sign); generating (E2) a pair of asymmetric encryption keys (pkEnc, skEnc) to implement the pseudo-homomorphic encryption function (Enc); 10 -transmission (E3) of the public encryption key of said pair of asymmetric encryption keys (pkEnc) and of the public signature key of said asymmetric signature key pair (pkSign) so that the client device realizes the ciphers and can check the signature tokens issued by the server using said public keys and that the server performs the decryptions and generates the signature tokens using the private keys of said asymmetric key pairs.
[0020]
20. The authentication method according to the preceding claim, wherein said encryption and / or signature keys are associated with an identifier of the customer holding the client device.
[0021]
21. The authentication method according to the preceding claim, wherein said encryption and / or signature keys are matched with an identifier of the customer holding the client device in a database.
[0022]
22.The authentication method of claim 20, wherein said encryption and / or signature keys are derived from a hash of the client identifier holding the client device. 3027177 59
[0023]
23.The authentication method according to one of claims 1 to 3 wherein the authentication token is generated further using a secret user key (k). 5
[0024]
24. Authentication method according to the preceding claim, wherein the authentication token is obtained by encrypting the secret user key (k) and the proof generation key P using a second function. pseudohomomorphic encryption (Enc2). 10
[0025]
25. Authentication method according to the preceding claim, wherein the client device also has a first encrypted token (U1, U2) obtained by encryption of the user secret key using a first pseudo encryption function - Homomorphic (Enc1) and further comprising a transmission step (F11) by the client device to the server of the first encrypted token.
[0026]
26.The authentication method according to the preceding claim comprising a step of determining (F81) a first parameter (t) by the client device and a second encrypted token (R1, R2) obtained by encryption of the secret key user (k) and said first parameter (t) using the first pseudo-homomorphic encryption function (Enc1) and a transmission step (F11) by the client device to the server of the second encrypted token.
[0027]
27. Authentication method according to the preceding claim wherein: the generation step (A1) of a secret element knowledge proof (PIN) comprises the transmission of a challenge (r) (F7) By the server to the client device, and the generation by the client device of a signature data item (Z) obtained from the first parameter (t), a first value of hash (c) and the key of masked proof generation (P * 8), said first value of 5 hash (c) being obtained from the received challenge (r), the first encrypted token (U1, U2), the masked authentication token (J ') using the first mask data (8) and the second encrypted token (R1, R2), - the step of transmission (A2) to the server by the client device of said secret element knowledge proof comprises transmitting (F9) by the client device, said signature data (Z) to the server.
[0028]
28. Authentication method according to the preceding claim, wherein the steps of verification by the server of the validity of the masked authentication token received (A4) and the validity of the proof of knowledge (A6) comprise: computing (F12) a second hash value (c ') from the challenge (r), the first encrypted token (U1, U2), the masked authentication token (J') and the second encrypted token ( R1, R2) received; computing (F13) a first deciphered token (K ') by decrypting the first encrypted token (U1, U2) using the first pseudo-homomorphic encryption function (Enc1); The calculation (F14) of a proof verification key (T ') by decryption of the masked authentication token (J') by means of the second pseudo-homomorphic encryption function (Enc2); computing (F15) a second deciphered token (R) by decrypting the second encrypted token (R1, R2) using the first pseudo-homomorphic encryption function (Enc1); checking the validity of the received masked authentication token and the proof of knowledge from the received signature data (Z), the first decrypted token (K '), the second decrypted token (R), the second value of hash (c ') and the proof verification key (T').
[0029]
29. A computer program product comprising program code instructions for performing the steps of the method according to any one of the preceding claims when said program is run on a computer.
[0030]
Client device characterized in that it is configured to: hold an authentication token (J) generated using a pseudo-homomorphic function and from a secret element (PIN); generate a secret element knowledge (PIN) proof from a masked proof generation key (P) with a first mask data item (p), said first mask data item 20 being a known non-public random data item only of the client device and said masked proof generation key (P) being constructed so as to prove the knowledge of said secret element (PIN) without disclosing it, - to transmit to the server said proof of knowledge of the secret element generated, transmitting to the server the masked authentication token (J) using the first mask data (p), so that the server verifies the validity of the received masked authentication token and verifies the validity of the evidence of knowledge. 3027177 62
[0031]
31.A client device authentication server using a secret element (PIN), said client device holding an authentication token (J) generated using a pseudohomomorphic function and from said secret element (PIN), said server being configured to: - receive a proof of knowledge of the secret element (PIN) generated from a masked proof generation key (P) with a first mask data item (13) ) and transmitted by the client device, said first mask datum being a non-public random datum known only to the client device and said masked evidence generation key being constructed to prove knowledge of said secret element (PIN) without disclosing it receive the masked authentication token (J) using the first mask data (p); check the validity of the received masked authentication token; check the validity of the proof of authentication; nnaissance.
[0032]
32.System comprising at least one client device according to claim 30 and a server according to claim 31.

类似技术:

---

公开号 | 公开日 | 专利标题

---

EP3010177B1|2018-07-25|Method for authenticating a client device with a server using a secret element

---

US10211981B2|2019-02-19|System and method for generating a server-assisted strong password from a weak secret

---

EP3259724B1|2021-03-24|Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system

---

EP3005608B1|2019-07-17|Authentication

---

EP1526676A1|2005-04-27|Conference session key distribution method on an id-based cryptographic system

---

EP2345202B1|2017-04-05|Digital signature method in two steps

---

US20120023336A1|2012-01-26|System and method for designing secure client-server communication protocols based on certificateless public key infrastructure

---

CN103414690A|2013-11-27|Publicly-verifiable cloud data possession checking method

---

US9531540B2|2016-12-27|Secure token-based signature schemes using look-up tables

---

EP3506556B1|2020-08-05|Method of authenticated key exchange via blockchain

---

CN110999202A|2020-04-10|Computer-implemented system and method for highly secure, high-speed encryption and transmission of data

---

CN107395627B|2020-07-17|Lightweight authentication protocol based on one-way function

---

CN106789032A|2017-05-31|The single password tripartite authentication method of privacy sharing between server and mobile device

---

Liu et al.2018|Asymmetric subversion attacks on signature schemes

---

KR100989185B1|2010-10-20|A password authenticated key exchange method using the RSA

---

Kim et al.2011|Further improved remote user authentication scheme

---

Al-Attab et al.2016|Authentication scheme for insecure networks in cloud computing

---

Om et al.2017|Comment and modification of RSA based remote password authentication using smart card

---

Ghilen et al.2014|Classification of quantum authentication protocols and calculation of their complexity

---

Kuchta et al.2017|Secure certificateless proxy re-encryption without pairing

---

Islam et al.2011|Improved remote login scheme based on ECC

---

CN108924103A|2018-11-30|The on-line/off-line of identity-based towards cloud storage can search for encryption method

---

EP3965361A1|2022-03-09|Data exchange between a client and a remote device, for example a secure module

---

Chandravathi et al.2017|A New Hybrid Homomorphic Encryption Scheme for Cloud Data Security

---

Moghaddam et al.2014|SUAS: Scalable user authentication scheme for secure accessing to cloud-based environments

同族专利:

---

公开号 | 公开日

---

FR3027177B1|2016-11-04|

---

EP3010177A1|2016-04-20|

---

EP3010177B8|2018-09-12|

---

EP3010177B1|2018-07-25|

---

US20160105414A1|2016-04-14|

---

US10027654B2|2018-07-17|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US20070204078A1|2006-02-09|2007-08-30|Intertrust Technologies Corporation|Digital rights management engine systems and methods|

---

WO2008022158A2|2006-08-14|2008-02-21|The Regents Of The University Of California|System for non-interactive zero-knowledge proofs|

---

EP2359526B1|2008-11-04|2017-08-02|SecureKey Technologies Inc.|System and methods for online authentication|

---

US8627422B2|2010-11-06|2014-01-07|Qualcomm Incorporated|Authentication in secure user plane location systems|CN106301788B|2016-08-12|2019-03-19|武汉大学|A kind of group key management method for supporting user identity authentication|

---

FR3058292B1|2016-10-31|2019-01-25|Idemia Identity And Security|METHOD FOR PROVIDING SERVICE TO A USER|

---

EP3316549A1|2016-10-31|2018-05-02|Idemia Identity & Security France|Method for verifying the identity of a user by means of a public database|

---

FR3059802B1|2016-12-07|2018-11-09|Safran Identity & Security|METHOD FOR GENERATING AN ELECTRONIC SIGNATURE OF A DOCUMENT ASSOCIATED WITH A CONDENSATE|

---

US11196541B2|2017-01-20|2021-12-07|Enveil, Inc.|Secure machine learning analytics using homomorphic encryption|

---

US10693627B2|2017-01-20|2020-06-23|Enveil, Inc.|Systems and methods for efficient fixed-base multi-precision exponentiation|

---

US20180212753A1|2017-01-20|2018-07-26|Enveil, Inc.|End-To-End Secure Operations Using a Query Vector|

---

US10771237B2|2017-01-20|2020-09-08|Enveil, Inc.|Secure analytics using an encrypted analytics matrix|

---

US10530585B2|2017-06-07|2020-01-07|Bar-Ilan University|Digital signing by utilizing multiple distinct signing keys, distributed between two parties|

---

KR101945885B1|2017-07-07|2019-06-11|서울대학교산학협력단|Method for Authenticating Evaluation Results of Homomorphic-Encrypted Data|

---

CN110661610B|2018-06-29|2020-11-03|创新先进技术有限公司|Input acquisition method and device of secure multi-party computing protocol|

---

US10902133B2|2018-10-25|2021-01-26|Enveil, Inc.|Computational operations in enclave computing environments|

---

US10817262B2|2018-11-08|2020-10-27|Enveil, Inc.|Reduced and pipelined hardware architecture for Montgomery Modular Multiplication|

---

FR3113800A1|2020-09-02|2022-03-04|Idemia Identity & Security France|Data exchange between a client and a remote device, for example a secure module|

法律状态:
2015-09-28| PLFP| Fee payment|Year of fee payment: 2 |

---

2016-04-15| PLSC| Search report ready|Effective date: 20160415 |

---

2016-09-21| PLFP| Fee payment|Year of fee payment: 3 |

---

2017-09-21| PLFP| Fee payment|Year of fee payment: 4 |

---

2018-09-19| PLFP| Fee payment|Year of fee payment: 5 |

---

2019-09-19| PLFP| Fee payment|Year of fee payment: 6 |

---

2020-09-17| PLFP| Fee payment|Year of fee payment: 7 |

---

2021-09-22| PLFP| Fee payment|Year of fee payment: 8 |

优先权:

---

申请号 | 申请日 | 专利标题

---

FR1459804A|FR3027177B1|2014-10-13|2014-10-13|METHOD OF AUTHENTICATING A CLIENT DEVICE FROM A SERVER USING A SECRET ELEMENT|FR1459804A| FR3027177B1|2014-10-13|2014-10-13|METHOD OF AUTHENTICATING A CLIENT DEVICE FROM A SERVER USING A SECRET ELEMENT|

---

US14/881,014| US10027654B2|2014-10-13|2015-10-12|Method for authenticating a client device to a server using a secret element|

---

EP15189617.2A| EP3010177B8|2014-10-13|2015-10-13|Method for authenticating a client device with a server using a secret element|